\section{User Centered Design}
\subsection{Introduction}
This chapter will look into how the design process should be structured and why it is important to include the user in this. The following is based on the book "Interaction Design - beyond human-computer interaction" by Sharp, Rogers and Preece \cite{interactionDesign}.

When designing a product with an interface, some designers forget that the product they are making is build for the user - not the designer. A certain design might seem both logical, aesthetically pleasing and intuitive to the designer, but it is not a prerequisite that the user will think the same. This is why it is important to include the user through the entire design process - from its early concept draft to the final design.

\subsection{Gathering Data}
Already from the start it's important to know the needs of the user. The designer has an idea for a product and its target group, but should not feel certain at this point whether that idea is any good. Data needs to be gathered from the intended group to determine their needs and upon these construct the requirements for the design. Even though this first step is very important, it's limited how much can be concluded this early in the design process. There are five ways to gather data:

\begin{enumerate}
\item Questionnaires: Quantitative and qualitative. Needs to be very well structured to give the right answers. Doesn't require much work force to conduct, but might take time before sufficient answers are given. Questionnaires were used in this project.
\item Interviews: Mostly qualitative. Time-consuming depending on the amount of interviewees, but can give more personal and richer data for analysis. Interviews were also used in this project to investigate the potential of the initial problem.
\item Focus groups: Mostly qualitative. Helps determining requirements for the product through discussion. Time-consuming.
\item Observation: Qualitative. Very time consuming. Can give some very detailed insight into the target group and how they use (or would use) the product. Observations can be controlled experiments, field experiments, or natural obserations.
\item Documentation: Quantitative. Takes little time to conduct. Looks on data already gathered. Rarely very useful data.
\end{enumerate}

Early on, a fairly unstructured interview was conducted to investigate whether there was a potential problem. A questionnaire could work also, but an unstructured interview is faster and it is harder to design the questions in a questionnaire properly to get the right answers this early in design. Furthermore, it's possible to look at already recorded documentation, but often this is so unspecified towards the product that it rarely does much good.

\subsection{Needs and Requirements}

Whatever way of gathering data is chosen, some needs of the user will come out of it. From these its possible to construct some requirements for the design. These requirements can be divided into two categories: \textit{Functional} and \textit{non-functional} requirements. The functional requirements are simply what the product is supposed to do; what the user expects to be possible with the product. This should not be confused with the designer's personal vision for the product. The non-functional requirements can be further divided into 4 sub-categories:
\begin{enumerate}
\item Data requirements: What data does the program need to handle or access?
\item Environmental requirements:
\begin{enumerate}
\item Physical: Where will the product be used? Will external factors (e.g. lighting, wind, acoustics, noise) cause a problem?
\item Social: What social aspects do the product serve? How will the product do in social environments?
\item Organizational: How much support does the product give? Is there sufficient helpful information?
\item Technical: What will the product run on? Are there technical limitations?
\end{enumerate}
\item User requirements: Does the product fit the target group? What is required for that group to enjoy this product to its fullest?
\item Usability requirements: This will be looked more into in the next sub-section.
\end{enumerate}

\subsection{Usability and User Experience}
\textit{Usability} requirements is a larger section all by itself. Usability can be divided into six categories to more easily grasp it:
\begin{enumerate}
\item Effectiveness: Does the program do what it is supposed to do? Does it have the expected functionality?
\item Efficiency: Easy, simple and quick interface \textit{"[...] an efficient way of supporting common tasks is to let the user use single button or key presses."}\cite{interactionDesign}
\item Safety: \textit{"[...] (i) preventing the user from making serious errors by reducing the risk of wrong keys/buttons being mistakenly activated (an example is not placing the quit or delete-file command right next to the save command on a menu) and (ii) providing users with various means of recovery should they make errors."}\cite{interactionDesign}
\item Utility: Can users do what they want to do? How much freedom does the program give them? How many things are locked in and not changeable? \textit{"Does the system provide an appropriate set of functions that enable users to carry out all their tasks in the way they want to do them?"}\cite{interactionDesign}
\item Learnability: \textit{"How easy is it and how long does it take (i) to get started using a system to perform core tasks and (ii) to learn the range of operations to perform a wider set of tasks?"}\cite{interactionDesign}
\item Memorability: \textit{"What kinds of interface support have been provided to help users remember how to carry out tasks, especially for systems and operations that are used infrequently?"}\cite{interactionDesign} Is everything structured intuitively, so things can easily be found later on?
\end{enumerate}

Usability is about what the program should do, what it does, how it does it and how well it does it. All these are requirements, but they don't have a right or wrong answer. The only way to know whether a design is good, is to make several design drafts and compare and show them to the target audience. \textit{"Generating alternatives is a key principle in most design disciplines, and one that should be encouraged in interaction design."}\cite{interactionDesign} Some parts of usability might even work against each other, such as a high utility might make it harder to learn, or a high focus on safety might slow down the efficiency of the product. Balancing these especially requires participation from the users. 

If usability is the logical requirements of the design, then \textit{user experience} is how the product feels. How a product feels is a big part of the design, but is a more abstract concept to grasp. Through the product the designer might want to stimulate interest and creativity. As with usability, this takes some balancing as some feelings work against each other. It is impossible to determine whether the product evokes the proper feelings without participation from the user. What a designer perceives as entertaining may be incredibly tedious to the target audience.

\subsection{Design Principles}
Designing a product is a mix of experience, theory, user data and common sense. Sometimes it can all seem very confusing. To make it more manageable are here some simple guidelines to follow. These do not explain directly what to do with a specific design, but serve as a reminder on things to be aware of when designing a product. These guidelines served the group as pinpoints through the design process. The report will not refer back to them.
\begin{enumerate}
\item Visibility: The relationship between position and task. Easily visible and in a position that makes sense.
\item Feedback: Works in unison with visibility. A quick and apparent feedback helps the user understand how to interact with a function.
\item Constraints
\begin{enumerate}
\item Physical: Physical constraints like not being able to insert a CD in a tablet.
\item Logical: Constraints that are logical and can be deduced logically. If for instance some options have been disabled, it should be apparent why and easy to understand - logically.
\item Cultural: Tradition and standard. A cross in the corner of a program closes the program. An exclamation mark means error. Icons to represent programs. Things like that.
\end{enumerate}
\item Mapping: The relationship between buttons, position and effect. Buttons of near same effect should be placed close to each other and in logical placement next to each other. A good example is the arrow keys on the keyboard. They do almost the same, but are different. This difference is easily distinguishable through their logical placement next to each other.
\item Consistency: An action in one part of the program should be consistent through the entire program. This both helps in avoiding confusion with later elements of the program, when it doesn't do the same as before, and it helps learning the program, when everything can be learned bit for bit. When things become more complicated and broad, it's important to be able to categorize options. A good example of this is when right-mouse clicking an object. The user knows that this should bring up options for the object, but doesn't need to know beforehand what options. Another example is when everyday experience/knowledge is applicable. A good example is the "folders" in Windows. We know that physical folders contain things, have names, can be stored in other folders and can be categorized. All of this is true for the digital version of the folder in Windows. Therefore they intuitively make sense. The challenge is to determine what an action should be consistent with.
\item Affordances: Affordances is a little like logical constraints. When applied to physical interfaces it simply describes what is physically possible to do with a thing and what is most logical. A button can only be pressed, which then becomes its logical function. A real affordance. When talking digitally this is more a question of convention, since there are no real constraints, which in turn makes it more related to consistency and cultural constraints. A perceived affordance.
\end{enumerate}